Pluggable file-based digital rights management api layer for applications and engines

ABSTRACT

A pluggable file-based DRM (digital rights management) API (application program interface) layer for applications and engines. The invention defines a pluggable file-based DRM API layer such that mobile operators can choose to use any file-based DRM (FDRM) engine in their final product. An FDRM engine can be content agnostic (e.g., can range from an executable to a media file or ring-tone). In accordance with the invention, an application can become DRM aware by calling the novel file-based DRM APIs. Any FDRM engine can be plugged into the novel API layer such that applications can use the protected content. The API layer of the subject invention can be designed such that applications that are DRM aware by using the file-based DRM API layer can be DRM engine agnostic.

CROSS REFERENCE TO RELATED APPLICATION

This application is a division of U.S. application Ser. No. 11/111,651,filed Apr. 21, 2005 entitled “Pluggable File-Based Digital RightsManagement API Layer for Applications and Engines,” the entirety ofwhich is hereby incorporated herein by reference.

TECHNICAL FIELD

This invention is related to computer systems and more particularly to apluggable application program interface (API) that facilitates the useof digital rights management (DRM) content.

BACKGROUND

Technological advances in digital media players have created a newmarket channel for distribution of copyrighted content (e.g., music,video, pictures) to users. For example, a user can download and/or share(e.g., transfer) digital content via the Internet. Oftentimes, thisdownload and/or transferred content can violate copyright laws andrights of the owner of the work.

Recent developments in audio compression technologies have been directedto digital rights management (DRM) mechanisms in order to controlunauthorized distribution of copyrighted content. In general, theseaudio compression technologies make it feasible to download qualityaudio from the Internet expeditiously while limiting access and/orsharing of the content to only authorized users.

These compression techniques have revolutionized music distribution. Forexample, an hour of near CD-quality audio can be downloaded in less thanfive minutes using a standard home computer. Accordingly, publishershave tried to cope with this phenomenon by introducing and enforcingcopyright protections via the compression techniques. Overall,unauthorized downloading and/or sharing have become a major legal issuefor the music industry.

DRM is a mechanism for protecting the copyrights of digital content thatis distributed over the Internet. A DRM system can also include theaccounting for paying royalties to the authors of the material. Forexample, in the music industry, a typical DRM system can provide acontainer format that includes album and track titles along with a setof rules that can enforce copyright compliance. Accordingly, softwareand hardware media players should support the rules order to play backthe copyrighted material.

With respect to portable devices, there are several possible file-basedDRM engines required by mobile operators around the world.Unfortunately, today, it is not determined which DRM format a devicewill be required until a mobile operator and OEM (original equipmentmanufacturer) commence working together and well after productdevelopment has concluded.

What is needed is a system that defines a FDRM (file-based DRM) APIlayer such that mobile operators can choose to use any file-based DRMengine in their final product. Further, a need exists for a file-basedDRM engine that is content agnostic. In other words, the content canrange from an executable to a media file or ring-tone.

SUMMARY

The following presents a simplified summary of the invention in order toprovide a basic understanding of some aspects of the invention. Thissummary is not an extensive overview of the invention. It is notintended to identify key/critical elements of the invention or todelineate the scope of the invention. Its sole purpose is to presentsome concepts of the invention in a simplified form as a prelude to themore detailed description that is presented later.

The invention disclosed and claimed herein, in one aspect thereof,comprises a pluggable file-based DRM (digital rights management) API(application program interface) layer for applications and engines. Asdescribed supra, there are several possible file-based DRM (FDRM)engines required by mobile operators around the world. Unfortunately,the DRM format a device will be required to use is usually notdetermined until a mobile operator and OEM start working together andwell after product development has concluded. This uncertainty makes itdifficult for application developers to hard code a DRM API layer inadvance. Accordingly, aspects of this invention define a pluggable FDRMAPI layer such that mobile operators can choose to use any FDRM enginein their final product.

It will be appreciated that a FDRM engine is content agnostic (e.g.,content can range from an executable to a media file or ring-tone). Thesubject invention can facilitate an application to become DRM aware bycalling the novel FDRM APIs. Any FDRM engine can be plugged into thenovel FDRM API layer such that applications can use FDRM protectedcontent. The FDRM API layer of the subject invention can be designedsuch that applications that are DRM aware using the FDRM API layer canbe DRM engine agnostic.

In one aspect a FileDrmVerifyRightsEx API can take one additionalparameter than FileDrmVerifyRights. The one additional parameter can bea filter identifier that allows applications to filter content based onits intended use. Rather than hard coding specific filter rules intoapplications, the subject invention can define a mechanism for the DRMengine to filter content. This provides both the ability to switch to adifferent DRM scheme as well as the ability of the OEM (originalequipment manufacturer) or operator to customize the device.

In an aspect a globally unique identifier (GUID) can represent eachfilter and specify the intended use of the content (e.g., a ring tone).If the content has valid rights but does not meet the DRM engine definedcriteria for using the content in the intended manner thenFileDrmVerifyRightsEx can return failure (E_FDRM_NOTALLOWED). In anotheraspect, passing FDRMFT_NONE causes no filtering of the results. A filternot recognized by the DRM engine can treated as FDRMFT_NONE.

In yet another aspect thereof, an artificial intelligence component isprovided that employs a probabilistic and/or statistical-based analysisto prognose or infer an action that a user desires to be automaticallyperformed.

To the accomplishment of the foregoing and related ends, certainillustrative aspects of the invention are described herein in connectionwith the following description and the annexed drawings. These aspectsare indicative, however, of but a few of the various ways in which theprinciples of the invention can be employed and the subject invention isintended to include all such aspects and their equivalents. Otheradvantages and novel features of the invention will become apparent fromthe following detailed description of the invention when considered inconjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a general component block diagram of a system thatfacilitates making an application DRM (digital rights management) awarein accordance with an aspect of the subject invention.

FIG. 2 illustrates two exemplary user interfaces (UIs) that facilitatenotifying a user of download status in accordance with an aspect.

FIG. 3 is a UI flow diagram of using content in accordance with anaspect of the invention.

FIG. 4 is a UI flow diagram of previewing content in accordance with anaspect of the invention.

FIG. 5 is a UI flow diagram of use of content with expired rights (norights renewal) in accordance with an aspect of the invention.

FIG. 6 is a UI flow diagram of use of content pending activations inaccordance with a disclosed aspect.

FIG. 7 is a UI flow diagram of use of content that is active but not yetcurrent in accordance with an aspect of the invention.

FIG. 8 is a general block diagram that illustrates an exemplary aspectthat employs a file system filter and content handler while making anapplication DRM aware in accordance with a disclosed aspect.

FIG. 9 is a general block diagram that employs a verify rights componentand an acquire rights component in accordance with a disclosed aspect.

FIG. 10 illustrates an exemplary flow chart of procedures to verifyand/or acquire rights of a selected file in accordance with a disclosedaspect.

FIG. 11 is a general block diagram that illustrates a DRM API(application program interface) layer having multiple API components inaccordance with an aspect.

FIG. 12 illustrates an exemplary flow chart of procedures to verify DRMrights, acquire DRM rights and handle errors in accordance with adisclosed aspect.

FIG. 13 illustrates an architecture including an artificialintelligence-based component that can automate functionality inaccordance with an aspect of the invention.

FIG. 14 illustrates a block diagram of a computer operable to executethe disclosed architecture.

FIG. 15 illustrates a schematic block diagram of an exemplary computingenvironment in accordance with the subject invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The invention is now described with reference to the drawings, whereinlike reference numerals are used to refer to like elements throughout.In the following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of the subject invention. It may be evident, however, thatthe invention can be practiced without these specific details. In otherinstances, well-known structures and devices are shown in block diagramform in order to facilitate describing the invention.

As used in this application, the terms “component” and “system” areintended to refer to a computer-related entity, either hardware, acombination of hardware and software, software, or software inexecution. For example, a component can be, but is not limited to being,a process running on a processor, a processor, an object, an executable,a thread of execution, a program, and/or a computer. By way ofillustration, both an application running on a server and the server canbe a component. One or more components can reside within a processand/or thread of execution, and a component can be localized on onecomputer and/or distributed between two or more computers.

As used herein, the term to “infer” or “inference” refer generally tothe process of reasoning about or inferring states of the system,environment, and/or user from a set of observations as captured viaevents and/or data. Inference can be employed to identify a specificcontext or action, or can generate a probability distribution overstates, for example. The inference can be probabilistic—that is, thecomputation of a probability distribution over states of interest basedon a consideration of data and events. Inference can also refer totechniques employed for composing higher-level events from a set ofevents and/or data. Such inference results in the construction of newevents or actions from a set of observed events and/or stored eventdata, whether or not the events are correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources.

Following is a discussion a novel application program interface (API)layer that can host exemplary user interfaces (UIs) in order to addressdigital rights management (DRM) content. It is to be appreciated thatthe exemplary UIs shown and described in this specification are intendedto provide context to invention with respect to DRM enablingapplications by providing examples of how a centralized DRM engine UIcan be incorporated into a feature. Furthermore, it is not mandatory tofollow the exact UI flows illustrated herein if it does not suitindividual applications so long as DRM rules are adhere to. Stillfurther, it is to be appreciated that the API naming conventionsdisclosed herein are not intended to limit the scope and/orfunctionality of the invention in any way. Other APIs with the same orsimilar functionality can be employed using a completely differentnaming convention.

The following terms are used throughout the description, the definitionsof which are provided herein to assist in understanding various aspectsof the subject invention.

Prompt Based Rights refers to a general term for content that has countrights or the start of interval based rights associated therewith. Forexample, mobile operators may require a user to be notified prior tousing content with count or start of interval-based rights. Because theoperator requirements may be unclear, such registry keys can be providedto allow the operator to turn on or off the count or interval basedrights notifications. In the case where the operator chooses to suppressthe prompted based rights use notifications, content can be treated asnon-prompted based rights content. In general, the count and intervalbased rights will be referred to as ‘prompt based rights’ since they mayrequire a user prompt prior to rendering content.

Forward-Locked refers to content that is locked to the device and cannotbe forwarded for use on another device.

Referring initially to FIG. 1, system 100 in accordance with an aspectof the invention is shown. Generally, the system 100 includes a DRM APIcomponent 102 that enables an application 104 to communicate with a DRMengine 106. In order to enable application 104 to be DRM aware, theapplication 104 can employ the DRM API layer 102 when calling the DRMengine 106. In other words, application 104 does not call the DRM engine106 directly. It will be appreciated that if an application 104 is usingthe DRM API layer 102, the application will not compromise the DRMcontent or use it in any way other than in accordance with the DRM rulesand restrictions imposed via the DRM engine 106.

The DRM APIs 102 can act as a bit funnel for DRM content between the DRMengine 106 and DRM aware application 104. As stated previously, it willbe understood that, in accordance with the invention, all DRM protectedfiles can retain the same file extension and storage locationinfrastructure as its unprotected counterpart. In other words, theinvention can make application 104 DRM aware by using (e.g., plugging)the DRM API 104. DRM awareness includes using the DRM engine 106 andrelated UIs (not shown) to inform users of content use status. DRMawareness further includes allowing application 104 to use DRM protectedcontent with active rights and likewise preventing the application 104from saving altered copies of any protected content.

Furthermore, DRM awareness can prevent application 104 from forwardingor sending content locked to the device. It will be understood that, inanother aspect, application 104 can also facilitate use of DRM protectedcontent stored on removable storage cards. As previously stated, it isto be understood that DRM API layer 102 illustrated in FIG. 1 can berepresentative of a set of APIs including 1 to N disparate APIs, where Nis an integer. These 1 to N disparate APIs will be described in greaterdetails infra and can be referred to individually or collectively as DRMAPI layer 102.

Upon making the application 104 DRM aware, the application 104 willabide by all the applicable DRM use rules set forth by the DRM enginecomponent 106. For example, the application 104 can refer to theappropriate DRM engine 106 restrictions and/or operator requirements formore detailed use definitions and rules. Application 104 can work asusual if a DRM client is not included in the build. By way of example,an aspect of the invention can prevent DRM protected content from beingsaved or transferred (e.g., synced or sent) via inbox, calendar,ActiveSync, Bluetooth, Infrared, contacts, notes, removable storagecards, or the like.

In order to provide context to the invention, the following exemplaryscenarios are provided. It is to be appreciated and understood that thescenarios that follow are not intended to limit the invention in anyway. Of course, other scenarios exist that can employ novel features andfunctionality of the subject invention. Moreover, although the scenariosthat follow are directed to “smartphone” implementations, it is to beunderstood and appreciated that additional scenarios can exist wherebyother devices are employed. For example, other devices can include, butare not limited to include, cell phones, personal data assistants(PDAs), pocket personal computers (PPCs), desktop computers, laptopcomputers or the like.

A first scenario is directed to downloading content via a smartphone.Suppose Kate downloads DRM protected content from her operators' website onto her smartphone. In accordance thereto, a UI is displayed thattracks the download progress. When completed, the UI notifies Kate ofthe successful download and gives her the choice to open the content.Kate chooses not to open it. In this example, the content remains on herdevice in the event she turns it off. It will be appreciated that, ifthe content cannot be used, a user notification can inform Kate that thecontent cannot be used and was not saved on the device.

FIG. 2 illustrates two exemplary UIs that can be employed with referenceto the first scenario. As illustrated, exemplary UI 202 can be employedto notify a user (e.g., Kate) that the desired content has downloadedsuccessfully. Additionally, the UI 202 can inquire if the content is tobe used immediately. On the other hand, UI 204 can be employed to notifythe user (e.g., Kate) that the content (e.g., ring tone) selected cannotbe used on the present device and therefore will not be downloaded.

Another scenario is directed to the use of any active DRM protectedcontent, for example, a ring tone. Suppose Kate wants to select a newring tone for her smartphone. Accordingly, she scrolls through her ringtones in the sounds spin box and selects a desired tone. In thisexample, she chooses a ring tone that she downloaded from her operators'website. Kate pauses on the desired ring tone, hears a short previewthen presses done. As a result, the ring tone is now set and hersmartphone rings using the chosen ring tone. Although this scenario isdirected to a ring tone, it is to be understood that this scenario issimilar for any DRM aware application using protected content.

FIG. 3 illustrates this scenario whereby the user (e.g., Kate) selectsto use the ring tone. For example, UI 302 can be displayed to facilitateselection of a “sound” content file. Once “DONE” is selected via the UI302; the user can be prompted with UI 304, which facilitates selectionof a particular “sound” file. After a desired sound file is selected at304, a determination is made if the selection contains prompt-basedrights at 306. If the selection does contain prompt-based rights, UI 308can be displayed to advise of the particular prompt-based rights as wellas to query the user if a desire exists to use the prompt-based rights.If answered in the affirmative, the content can be set at 310. If not,the selection UI 304 can be rendered. If a determination is made at 306that the selection does not contain prompt-based rights, the content canbe set at 310 as illustrated.

Another example is directed to the use of any inactive DRM protectedcontent, for example, a ring tone. As in the previous scenario, supposeKate wants to select a new ring tone for her smartphone. She scrollsthrough her ring tones in the sounds spinbox and pauses on a desiredring tone. However, in this instance, there is no sound preview and shepresses done. The UI notifies Kate that the desired ring tone is nolonger activated and gives her the option of connecting to a web site toacquire new rights. Kate elects to buy new rights and is connected tothe rights issuer website. While she is waiting for the rights, thedefault ring tone is used. Once the new rights arrive, she is notifiedvia a SMS (short message service) text message. Accordingly, Kate'ssmartphone now rings using the desired ring tone. It is to beappreciated that the content (e.g., ring tone) can be protected suchthat Kate is unable to renew the rights. In this case, she will benotified that the content cannot be used.

FIG. 4 illustrates a UI flow diagram of previewing content in accordancewith an aspect of the invention. More particularly, content (e.g., ringtone) can be selected via the exemplary UI 402. At 404, a user can electto pause on the content. If pause is not selected, the system returns tothe UI of 402 to enable another selection. If paused, at 408, the systemcan determine if prompt-based rights exist. At 410, the details of theprompt-based rights can be conveyed to the user whereby the user canconfirm desire to continue. Once the user confirms to continue at 410,the content is played at 412. As well, if at 408 it is determined thatprompt-based rights do not exist, the system can play the content at 412as illustrated.

Turning now to the UI flow diagram of FIG. 5, a UI flow diagram of useof content with expired rights (no rights renewal) in accordance with anaspect of the invention is shown. Essentially, at 502, a UI is presentedto the user to facilitate selection of the type of content (e.g., sound)to download. At 504, a UI can be launched to enable a user to select aparticular file of the selected type. The UI of 506 can advise the userof expired content. It will be appreciated, as described herein,additional UIs can be presented to enable renewal or access toadditional rights to use the content.

FIG. 6 illustrates a UI flow diagram of use of content pendingactivations in accordance with a disclosed aspect. As shown, at 602 and604, UIs can be rendered that enable a user to select the type andspecific file to download and/or open. At 606, a UI can be rendered thatnotifies a user that the selected content is pending activation.Accordingly, the system can notify the user via a text message oncerights are in place. The content is set at 608 and will automaticallybecome available to the user once rights are in place.

Similar to FIG. 6, FIG. 7 is a UI flow diagram of use of content that isactive but not yet current in accordance with an aspect of theinvention. In accordance therewith, at 702 and 704, the type of contentcan be selected together with a specific file name to download and/oropen. At 706, a UI can be presented that notifies a user that theselected content will be activated will be available in N days, where Nis an integer. At 708, the content can be set and will automaticallybecome available once the appropriate rights are in place.

Yet another scenario is directed to receiving forward-locked protectedcontent via MMS. Kate receives a message containing forward-lockedcontent (e.g., image, sound). She can employ the content as she wouldany unprotected content. Kate tries to forward the message with thecontent to a friend; however, the UI notifies her that the contentcannot be forwarded. Although, the content cannot be forwarded, Kate cansave the image to her device with no modifications. She deletes theoriginal message and can view use the content again so long as rightsallow.

Still another example is directed to sending protected content. SupposeKate composes a message and inserts a forward-locked sound. The UInotifies her that this content cannot be sent from her device. Kate thenchooses another sound. The UI notifies her that the recipient will berequired to obtain rights prior to using the content. Kate previews themessage. If rights are current and are not prompt based, Kate sees thepreview of the attachment. If rights are current and prompt based,before previewing, the UI notifies Kate that her rights status willadjust. If the rights have expired, Kate will be given the opportunityto buy new rights if that option is available. In this case, the contentcannot be previewed until new rights are received. When Kate issatisfied with her message, she chooses to send it.

In operation, applications can explicitly call the DRM APIs to accessprotected content. In one aspect, a user attempting to use content withexpired renewable rights will be prompted with a UI that enables theuser to reactivate rights. In another aspect, a user attempting to usecontent that has expired non-renewable rights will be notified that thecontent cannot be used. In still another aspect, a user attempting touse content with prompt based rights will cause a UI to appear askingthe user if they want to alter the status (e.g., reduce count or startinterval) of their rights if this UI is not suppressed by the operatorsetting a registry key.

In accordance with the invention, an API (or set of APIs) can allowapplications to be written to support a variety of file-based digitalrights management (FDRM) technologies without understanding theintricacies of the DRM schema. In accordance with an aspect, a common UIfor DRM related tasks is supplied by an engine that allows theapplication to take advantage of engine specific DRM features withoutunderstanding them. Additionally, if the UI is not suitable for aparticular scenario, it can be suppressed by the application call to theFDRM API layer.

Essentially, the subject invention wraps a DRM engine in a generic setof DRM APIs thus enabling non-DRM aware applications to become DRM awareby calling the generic set of DRM APIs. It will be understood that, inaccordance with an aspect, all DRM protected files can retain the samefile extension and storage location infrastructure as its unprotectedcounterpart. Additionally, a user can rename protected content and makemultiple copies (e.g., backup) of protected content. DRM content can bestored in a protected format on a removable storage card or desktop and,if DRM rights permit, the content can be accessed directly from thesestorage locations.

As described supra, the subject invention is directed to a novel set ofAPIs that define an interface to DRM content on device (e.g., mobiledevice). This set of APIs can wrap any DRM solution in a form thatallows applications to use DRM content without changes. It will beunderstood that this novel feature allows the use of any DRM scheme.Devices without DRM protection can still use these same APIs.

Referring now to FIG. 8, a system 800 can generally include a DRM APIlayer 802, an application 804 and a DRM engine 806. As illustrated, theDRM engine 806 can include a file system filter 808 and a receivedcontent handler 810. The API can be a stub that calls into the DRMengine API implementation layer if present on a device. If there is noDRM engine the stub provider can work as if all content has allavailable rights.

In one aspect, content can be stored on the device in the same locationand with the same filename it would have had if it was not protectedcontent. Protected content can be stored in such a way that contentsharing across multiple devices is impossible without the other devicesacquiring rights for that content. In accordance with the invention, itis possible to move or copy content to other locations on the samedevice, store content on removable storage cards, and to back upcontent. An application 804 can employ the file APIs to work with files,however files opened with a CreateFile call instead of a DRM CreateFilecall will return “garbage” when read. These calls will be betterunderstood upon a reading of the discussion that follows. The inventioncan also block writes to files containing DRM protected content.

In accordance with the invention, DRM protected content will have a setof rights associated with it that can define how the device can usecontent. For instance, an image can have rights that allow a user todisplay the image but not to forward the image to another user. This API802 employs content that is not DRM protected as having all possiblerights.

Limits on how long or how often the content can be used are alsopossible. For example, limitations can be placed on the use of a soundfile. For instance, a sound file can be limited to a predefined numberof plays (e.g., 10 times), a play time period (e.g., only until March 1,for two weeks from the time first used) or a combination thereof (e.g.,or only 10 times until March 1). Once these limited rights have beenexhausted, it may be possible for the user to acquire additional rights.An application 804 or DRM engine 806 can initiate acquisition of newrights when handling the error caused by expired rights in accordancewith the invention.

In one aspect, the DRM engine 806 can be responsible for providing mostof the user interaction for displaying or renewing rights associatedwith a content protected object. For this purpose, some calls may take along time to complete, as an interaction with a remote rights managementserver (not shown) may be required.

In general, application 804 does not create protected content. Anapplication 104 that receives protected content can call a contenthandler 810, which stores the content in the device file system andstores the content rights in a rights store. The DRM engine 802 cansupply this content handler 810. Although FIG. 8 illustrates the contenthandler 810 included within the DRM engine 802, it is to be appreciatedthat the content handler 810, and file system filter 808 can be externalcomponents from the DRM engine 806. The rights associated with thecontent may not be included with the received content. For example, in awireless aspect, the rights associated with the content can be receivedseparately using a WAP (wireless application protocol) push. As well, itwill be appreciated that the content and/or the rights associatedtherewith can be stored remote from the device. The DRM engine 806 canbe responsible for receiving these rights, storing them in the rightsstore, and notifying the user of the rights.

Referring now to FIG. 9, the DRM API layer 802 can include a verifyrights component 902 and an acquire rights component 904. The verifyrights component 902 (e.g., FileDrmVerifyRightsEx API) can take a filteridentifier parameter that facilitates application 804 to filter contentbased on an intended use of content. Rather than hard coding specificfilter rules into the application 804, the invention provides amechanism (e.g., verify rights component 902) for the DRM engine 806 tofilter content. This mechanism provides both the ability to switch to adifferent DRM scheme as well as the ability of the original equipmentmanufacturer (OEM) and/or operator to customize the device.

In one aspect, the invention employs global unique identifiers (GUIDs),which represent each filter, and specifies the intended use of thecontent (e.g., a ring tone). If the content has valid rights but doesnot meet the DRM engine 806 defined criteria for using the content inthe intended manner then the file system filter 808 returns failure(e.g, E_FDRM_NOTALLOWED) to the verify rights component 902 (e.g.,FileDrmVerifyRightsEx). It is to be understood that passing FDRMFT_NONEcan cause no filtering of the results. A filter not recognized by theDRM engine is treated as FDRMFT_NONE.

With continued reference to FIG. 9, the acquire rights component 904 canbe provided to facilitate a user to obtain necessary rights to use thecontent. As well, the acquire rights component can facilitate the userto renew cancelled and/or expired rights.

In one aspect, implementations of the DRM engine 806 can export thefunctions implementing these APIs (e.g., 802) from a dynamic linklibrary (dll) by ordinal using the following mappings:

FileDrmIsDRM @1 NONAME ** RESERVED ** 2 FileDrmCreateFile @3 NONAMEFileDrmCreateForwardableContent @4 NONAME FileDrmNotifyEnable @5 NONAMEFileDrmNotifyDisable @6 NONAME FileDrmShowLicenseInfo @7 NONAMEFileDrmHandleError @8 NONAME FileDrmRenewRights @9 NONAMEFileDrmGetMetric @10 NONAME FileDrmVerifyRights @11 NONAMEFileDrmCommitRights @12 NONAME FileDrmDeleteFile @13 NONAMEFileDrmStoreContent @14 NONAME **RESERVED for use by existing 15-24 DRMengines ** FileDrmVerifyRightsEx @25 NONAME **RESERVED for future 26-74extensions **

The functions that implement the APIs 802 set forth in the above tablewill be each described in greater detail infra

FIG. 4 illustrates a methodology of implementing APIs in accordance withthe invention. While, for purposes of simplicity of explanation, the oneor more methodologies shown herein, e.g., in the form of a flow chart,are shown and described as a series of acts, it is to be understood andappreciated that the subject invention is not limited by the order ofacts, as some acts may, in accordance with the invention, occur in adifferent order and/or concurrently with other acts from that shown anddescribed herein. For example, those skilled in the art will understandand appreciate that a methodology could alternatively be represented asa series of interrelated states or events, such as in a state diagram.Moreover, not all illustrated acts may be required to implement amethodology in accordance with the invention.

With reference now to FIG. 10, at 1002 a file name is selected. At 1004,rights are verified. It will be appreciated that, in addition toverifying the existence of rights, the validity of any rights can alsobe verified at 1004. A determination is made at 1006 if the rights aresufficient to utilize the content of the file selected at 1002.

If the rights are sufficient, the rights are committed at 1008. Thesuccess of committing the rights can be verified at 1010. If successful,the file can be used at 1012. On the other hand, if the rights are notsufficient to enable use of the file content at 1006 or the commitrights fails at 1010, appropriate rights can be acquired at 1012. Onceacquired, the rights are verified at 1004.

If the rights are not successfully verified at 1006, some DRM API errorcodes prompt one or more DRM engine UIs in accordance with the instanterror code. For example, in one aspect, an error code that reflectsrights license is pending (e.g., E_FDRM_LICENSEPENDING) prompts anappropriate DRM engine UI. In another example, an error upon attemptingto forward content without forwarding rights (e.g.,E_FDRM_NOFORWARDRIGHTS) will prompt the DRM engine to initiatecorresponding UIs. In still another example, if rights have not beenobtained or are no longer valid an error code will be generated (e.g.,E_FDRM_NOTALLOWED) thus effecting the DRM engine to launch theappropriate UIs. Other error codes can be handled by the callingapplication with no UI.

As described supra, API layer component 802 can include 1 to N disparateAPIs, where N is an integer. FIG. 11 illustrates that 1 to N disparateDRM APIs can be referred to individually or collectively as DRM APIcomponent 1102.

Following is a discussion of an exemplary set of DRM APIs 1102 inaccordance with an aspect of the invention. It is to be appreciated thatthese exemplary DRM APIs 1102 are included to provide context to theinvention and is not intended to limit the invention in any way.Following is the exemplary list of DRM APIs 1102 for managing FDRMcontent in accordance with the invention. As well, for each API listed,a brief description of the API functionality is listed in the rightcolumn of the table below.

API (1102) FUNCTION FileDrmIsDRM Determine if an object is FDRMprotected FileDrmCreateFile Open a file containing FDRM contentFileDrmCreateForwardableContent CreateForwardableContentFileDrmNotifyEnable Enable FDRM provider notificationsFileDrmNotifyDisable Disable FDRM provider notificationsFileDrmShowLicenseInfo Show rights associated with an objectFileDrmHandleError Display error UI/try to correct problemFileDrmRenewRights Renew the rights for a FDRM object FileDrmGetMetricRetrieve FDRM metric FileDrmVerifyRights Verify that an object can beused FileDrmCommitRights Commit the rights used by an objectFileDrmDelete Delete an object and rights FileDrmStoreContent Storeprotected content on the device

Each of these exemplary APIs 1102 for dealing with FDRM content isdescribed in greater detail below. The description that follows isdirected to an exemplary DRM API layer. It is to be appreciated thatother aspects can exist that include all or a subset of the APIsdescribed infra. These alternate aspects are intended to be includedwithin the scope of the disclosed invention as well as the claimsattached hereto.

Referring to a discussion of error codes, as described supra, there area number of error codes, which can effect launching a DRM engine UI thatcan prompt user input. FIG. 12 illustrates a methodology of employingprotected content in accordance with an aspect of the invention. Aswell, FIG. 12 illustrates exemplary error codes that can prompt DRMengine action (e.g., UI).

At 1202 a file to use is selected. Next, at 1204, a verify rights API iscalled. In one aspect, the verify rights API can be aFileDrmVerifyRights API. A determination of success is made at 1206. Itwill be appreciated that the methodology can included a file inspectionAPI such as FileDrmIsDRM which can determine if the file contains DRMprotected content.

If at 1206 a determination is made that the rights are verified, acreate file API can be called. In the example, a FileDrmCreateFile APIcan be called whereby the file that contains the FDRM content can beopened. At 1210 a determination is made if successful. If successful inopening the file, rights can be committed at 1212. In order to do so, aFileDrmCommitRight API is employed to commit the rights used by theselected object.

Once the rights are committed at 1212, a determination is made if the ifcommitting the rights was successful. If so, the file can be used at1216. A determination is made if the file is persisted at 1218. If it isdetermined that the file is persisted, the rights are verified at 1220.For example, the FileDrmVerifyRights API can be called to verify therights. Accordingly, another success determination is made at 1222. Ifsuccessful, the methodology returns to 1216 to use the file. If notsuccessful at 1222, a stop block is reached.

Continuing with the example and returning to 1206, a determination ofrights verification is made from 1204. If determined not successful at1206, the system determines if the operation should succeed at 1224. Ifthe operation should succeed at 1224, a default filename is selected at1226. Once selected at 1226, the system can return to 1204 to verify therights.

However, if at 1224, a determination is made that the operation does nothave to succeed, a handle error API (e.g., FileDrmHandleError) can becalled. In accordance therewith, an error UI can be displayed to attemptto correct the problem. At 1230, a determination is made if the problemhas been rectified. If not, a stop block is reached. If the error ishandled, error information can be displayed at 1232.

In the exemplary aspect, some of the DRM API error codes require DRMengine UI interaction. For example, E_FDRM_LICENSEPENDING,E_FDRM_NOTALLOWED and E_FDRM_NOFORWARDRIGHTS require UI interaction. Allother error codes in the example can be handled by calling theapplication with no UI.

It is to be appreciated that each decision block (e.g., succeeded,persisted, handled) can generate error codes. Turning first to adiscussion of scenarios where an API call succeeds. In one aspect, theAPI call can succeed but no FDRM provider is installed. In thissituation, a code such as S_FDRM_NOPROVIDER can be generated. In anotherexample, an API call can succeed but, the passed in the object is notFDRM protected. A code such as S_FDRM_NOTDRMOBJECT can be generated.

Other exemplary error codes can be as follows:

E_FDRM_FILEDELETED—Object did not have rights and could not bere-activated. User choose to delete the object.E_FDRM_LICENSEPENDING—Object cannot be used now but there is anoutstanding request for some type of rights renewal.E_FDRM_CANCELLED—User chose not to use object with prompt-based rights.E_FDRM_NOTDRMOBJECT—API call failed since the passed in object was notFDRM protected.E_FDRM_NOTALLOWED—Requested operation is not allowed for this object orobject does not have sufficient rights to be used.E_FDRM_NOFORWARDRIGHTS—Object does not have rights to be forwarded.E_FDRM_NONOTIFY—Object was never registered for notifications.E_FDRM_NOPROVIDER—API call failed since no FDRM provider was installed.E_FDRM_UNKNOWNMETRIC—Unknown metric type requested from FDRM_GetMetric.E_FDRM_ERRORNOTHANDLED—Error could not be handled by FDRM_HandleError.

Returning to the exemplary API layer, names can be defined for resultsof HRESULT_FROM_WIN32 as follows:

#define E_INSUFFICIENT_BUFFER

HRESULT_FROM_WIN32(ERROR_INSUFFICIENT_BUFFER)

#define E_FILE_NOT_FOUND HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)#define FACILITY_FDRM FACILITY_ITF

The HRESULT codes can be started to avoid conflicting with COM-definedcodes:

#define CODE_OFFSET 0x0200#define S_FDRM_NOTDRMOBJECT MAKE_HRESULT(SEVERITY_SUCCESS,FACILITY_FDRM, (CODE_OFFSET+3))#define S_FDRM_NOPROVIDER MAKE_HRESULT(SEVERITY_SUCCESS, FACILITY_FDRM,(CODE_OFFSET+7))#define E_FDRM_FILEDELETED MAKE_HRESULT(SEVERITY_ERROR, FACILITY_FDRM,(CODE_OFFSET+0))#define E_FDRM_LICENSEPENDING MAKE_HRESULT(SEVERITY_ERROR,FACILITY_FDRM, (CODE_OFFSET+1))#define E_FDRM_CANCELLED MAKE_HRESULT(SEVERITY_ERROR, FACILITY_FDRM,(CODE_OFFSET+2))#define E_FDRM_NOTDRMOBJECT MAKE_HRESULT(SEVERITY_ERROR, FACILITY_FDRM,(CODE_OFFSET+3))#define E_FDRM_NOTALLOWED MAKE_HRESULT(SEVERITY_ERROR, FACILITY_FDRM,(CODE_OFFSET+4))#define E_FDRM_NOFORWARDRIGHTS MAKE_HRESULT(SEVERITY_ERROR,FACILITY_FDRM, (CODE_OFFSET+5))#define E_FDRM_NONOTIFY MAKE_HRESULT(SEVERITY_ERROR, FACILITY_FDRM,(CODE_OFFSET+6))#define E_FDRM_NOPROVIDER MAKE_HRESULT(SEVERITY_ERROR, FACILITY_FDRM,(CODE_OFFSET+7))#define E_FDRM_UNKNOWNMETRIC MAKE_HRESULT(SEVERITY_ERROR, FACILITY_FDRM,(CODE_OFFSET+8))#define E_FDRM_ERRORNOTHANDLED MAKE_HRESULT(SEVERITY_ERROR,FACILITY_FDRM, (CODE_OFFSET+9))

Continuing with the example, bitmasks for various rights associated withcontent can be defined:

#define FDRRF_PLAY 0x00000001 // Play audio/video content #defineFDRRF_DISPLAY 0x00000002 //Display images #define FDRRF_EXECUTE0x00000004 // Execute applications #define FDRRF_PRINT 0x00000008 //Print content #define FDRRF_FORWARD 0x00000010 // Content can beforwarded

Bitmask flags to control the FileDrmGetForwardContent API can be definedas follows:

#define FDRCF_BARE 0x00000001 // Bare file #define FDRCF_MIMEENCODED0x00000002 // Add needed MIME headers

Bitmask flags to control FileDrmVerifyRights and FileDrmCommitRightsAPIs can be defined. FDRVF_NOUI can suppress all UI display. This allowsthe calling application to ensure that this call will not block waitingfor user input. FDRVF_NORENEW does not attempt to update the rightsassociated with a piece of content (either through user interaction orautomatically).

FDRVF_VERIFY_CONTINUE can be specified when FileDrmCommitRights has beencalled and has returned success for a piece of content. As well, theconsuming application of the content can still be consuming the sameinstance of the content but needs to re-verify rights. For example, amedia player might begin playing a song but be interrupted by a phonecall. Once the phone call completes, the media player can callFileDrmVerifyRights to verify that it still has rights to continueplaying that content. This flag can allow content to continue being usedeven if the applicable rights are no longer valid. For instance, if thecontent has restrictions on the number of times it can be used and theusage count went to zero in the last call to FileDrmCommitRights thenthe user should still be allowed to use that content until is has beencompletely consumed. These bitmask flags can be defined as follows:

#define FDRVF_NOUI 0x00000001 // Do not show any UI #defineFDRVF_NORENEW 0x00000002 // No rights renewal #defineFDRVF_VERIFY_CONTINUE 0x00000004 // Verify continued use of content

Status values returned from FileDrmVerifyRights andFileDrmVerifyRightsEx can be as follows:

#define FDRVS_USER_CAN_UPDATE 0x00000001 // Right invalid but user canupdate #define FDRVS_UPDATE_PENDING 0x00000002 // A rights update ispending #define FDRVS_EXPIRABLE 0x00000004 // Rights are currently validbut can expire

Bitmask flags to control FileDrmHandleError can be specified. Thefollowing can be set by calling the application:

#define FDRHF_NOCORRECT 0x00000001 // Do not try to correct error

Next, examples that can be set by FileDrmHandleError are shown:

#define FDRHF_RETRY 0x00010000 // Calling app should retry op. #defineFDRHF_RIGHTSPENDING 0x00020000 // Rights update pending

Turning now to a discussion of the FDRMMETRIC API. Metric types can beretrieved using FileDrmGetMetric call. In one aspect, all time intervalsare returned in milliseconds. For example:

typedef enum tagFDRMMETRIC {  FDRM_METRIC_PREVIEW_TIME, // allowedpreview time  FDRM_METRIC_DELAY_TIME, // delay before prompting to userights  FDRM_METRIC_REVERIFY_TIME // How often to re-verify rights whenusing // content in a continuous manner } FDRMMETRIC;

As described supra, FilDrmVerifyRightsEx can take a filter identifierparameter that facilitates application 804 to filter content based on anintended use of the content. By way of example, filter identifiers forFileDrmVerifyRightsEx can be as follows:

// {5A3A54DD-209F-48e6-91DB-6A49F9238413} DEFINE_GUID(FDRMFT_NONE,0x5a3a54dd, 0x209f, 0x48e6, 0x91, 0xdb, 0x6a, 0x49, 0xf9, 0x23, 0x84,0x13); // {35AB44BA-B7D0-4548-9C3B-6864E9D08281}DEFINE_GUID(FDRMFT_RINGTONES, 0x35ab44ba, 0xb7d0, 0x4548, 0x9c, 0x3b,0x68, 0x64, 0xe9, 0xd0, 0x82, 0x81); //{B7EADA14-F373-4e12-BF17-0722B64362D5} DEFINE_GUID(FDRMFT_WALLPAPER,0xb7eada14, 0xf373, 0x4e12, 0xbf, 0x17, 0x7, 0x22, 0xb6, 0x43, 0x62,0xd5);

The FileDrmIsFDRM function can quickly determine if an object is FDRMprotected. In doing so, the following arguments can be employed:

// Arguments: //  [IN] pszFile - The fully qualified path to the filebeing checked, including the file extension. //  [OUT] pfDRM - A pointerto a BOOL variable which be set to TRUE if the object pointed to by thefile is DRM protected; FALSE otherwise.

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

// [SUCCESS] //  S_FDRM_NOPROVIDER //   The value pointed to by pfDRMwill be FALSE in this case. //  S_FDRM_NOTDRMOBJECT

The value pointed to by pfDRM will be FALSE in this case. This allows anapplication to display an indication that content is DRM protected.HRESULT FileDrmIsDRM (LPCTSTR pszFile, PBOOL pfDRM);

The function FileDrmCreateFile can facilitate a DRM-aware application toopen a DRM protected object. This function can be used in place of thestandard CreateFile API.

// Arguments: See CreateFile( ) for full details of each parameter.//  [IN] pszFileName -The fully qualified path to the file to be opened//  [IN] dwDesiredAccess - Type of access to the object. //  [IN]dwShareMode - Share mode for the object. //  [IN] lpSecurityAttributes -Ignored; set to NULL //  [IN] dwCreationDisposition - How to handleexisting/new files //  [IN] dwFlagsAndAttributes - File attributes forthe file. //  [IN] hTemplateFile - Ignored; set to NULL //  [OUT]phFile - Pointer to a handle variable that will hold the file handle ifthe call is successful.

In addition to the HRESULT return code the value pointed to by phFileshould be set to INVALID_HANDLE_VALUE if an error is returned. Thefunction is free to return any HRESULT and the application should usethe SUCCEEDED/FAILED macros to check the results. The following HRESULTcodes may be returned.

//  [SUCCESS] //    S_FDRM_NOPROVIDER //      The returned rightsstructure will allow for all rights. //    S_FDRM_NOTDRMOBJECT//      The returned rights structure will allow for all rights. //Sideeffects: File can be opened or created as appropriate. //Notes: UseCloseHandle to close the handle returned from this function.

This FileDrmCreateFile function is to be used in place of the standardCreateFile API by applications that are “FDRM Aware.” With someexceptions as detailed below, the function behaves the same way asCreateFile and returns any error that occurs during the call as theHRESULT created by HRESULT_FROM_WIN32 called on the value returned fromGetLastError( ). When the following conditions are true theFileDrmCreateFile works differently than CreateFile:

Case 1: Opening FDRM content for use.

1. An FDRM provider is installed.

2. The file being created already exists and contains FDRM protectedcontent.

3. dwDesiredAccess is set to GENERIC_READ

4. dwCreationDisposition is set to OPEN_EXISTING

In this case FileDrmCreateFile opens the file in such a way thatsubsequent calls to ReadFile will return the unencrypted version of thefiles content such that it can be used by the application.

Case 2: Attempting to open FDRM content for write access.

1. An FDRM provider is installed.

2. The file being created already exists and contains FDRM protectedcontent.

3. dwDesiredAccess is set to GENERIC_WRITE

In this case FileDrmCreateFile will fail to open the file (to preventapplications from inadvertently overwriting protected content).

Case 3: Attempting to delete/truncate FDRM content.

1. An FDRM provider is installed.

2. The file being created already exists and contains FDRM protectedcontent.

3. dwCreationDisposition is set to CREATE_ALWAYS or TRUNCATE_EXISTING.

In this case FileDrmCreateFile will fail to open the file (to preventapplications from inadvertently overwriting protected content).

HRESULT FileDrmCreateFile (LPCTSTR pszFileName, DWORD dwDesiredAccess,DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORDdwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile,PHANDLE phFile);

The FileDrmCreateForwardableContent function can create a filecontaining a DRM protected object in a way that allows it to beforwarded to another user.

// Exemplary Arguments are shown below: //  [IN] pszFileName - The fullyqualified path to the file to be forwarded. //  [IN] dwFlags - Flags tocontrol the format of the generated document. See the DRCF_* flags fordefined values. //  [IN] pszOutputFile - The fully qualified path for afile to hold the document // Return Values:

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//  [FAILURE] //    E_FDRM_NOPROVIDER //    E_FDRM_NOTDRMOBJECT//    E_FDRM_NOFORWARDRIGHTS // Side effects: A new file is createdholding the DRM protected content

Applications that want to forward content can use thisFileDrmCreateForwardableContent API to package format in such a way thatit can be sent to another device.

HRESULT FileDrmCreateForwardableContent (LPCTSTR pszFileName, DWORDdwFlags, LPCTSTR pszOutputFile);

Referring now to a discussion of the FileDrmNotifyEnable API, thepurpose of this API is to register an application with the DRM providerfor updates when updated rights are received on the device. Arguments inaccordance therewith can be as follows:

//  [IN] pszFileName - Fully qualified path to the file to receivenotifications //  [OUT] pszValueName -Pointer to a buffer to be filledwith the name of a registry DWORD value that will be updated when therights associated with the object change. The returned string shouldalways be terminated with a NUL character as long as cchValueLenis >= 1. //  [IN] cchValueLen - Length of the pszValueName buffer. Usinga buffer of size MAX_PATH can be sufficient. Passing in a smaller bufferwill cause this function to return E_INSUFFICIENT_BUFFER if the bufferis too small to hold the returned string (including the NUL terminator).

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//  [FAILURE] //    E_FDRM_NOPROVIDER //    E_FDRM_NOTDRMOBJECT//    E_INSUFFICIENTBUFFER

On success the psValueName can be filled in with the name of a registryvalue that can be monitored by the application. A new registry value mayhave been created in the registry. These values will be under the keyHKEY_CURRENT_USER\FDRM\Monitor. It will be appreciated that notificationof expiration of time or count based rights may not be supported.

An application that needs to know when a rights renewal has arrived canuse this function along with the RegistryNotifyxxxx functions to receivenotifications from the DRM provider. The DRM provider will take thepassed in filename and generate the name of a registry value that willbe used as a proxy for the file. The calling application can thenregister for registry notifications using this value. When the DRMprovider changes the rights store it will also write the new rightsvalue (using the DRRF_*values) to that registry value.

The DRM provider will reference count calls to FileDrmNotifyEnable andFileDrmNotifyDisable and only stop updating and remove the registryvalue when the reference count reaches zero. As well the DRM providerwill monitor processes and remove all outstanding references to thenotification upon process exit. Registrations by multiple processes orthreads within a single process that refer to the same filename shouldreturn the same registry value name to be monitored. The provider willalso monitor calls to DeleteFile and remove any outstandingnotifications when a FDRM protected file is deleted.

HRESULT FileDrmNotifyEnable (LPCTSTR pszFileName, LPTSTR pszValueName,DWORD cchValueNameLen);

The FileDrmNotifyDisable API allows the DRM provider to stop receivingnotifications of changes to the rights associated with a file.

// Arguments: //  [IN] pszFileName - Fully qualified path to the filethat the application no longer wants to receive notifications for.

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

// [FAILURE] //  E_FDRM_NOPROVIDER //  E_FDRM_NOTDRMOBJECT//  E_FDRM_NONOTIFY

See the description of FileDrmNotifyEnable supra for a description ofthis function.

HRESULT FileDrmNotifyDisable (LPCTSTR pszFileName);

The FileDrmShowLicenseInfo API can facilitate showing the rightsassociated with a DRM protected object.

// Arguments: //  [IN] hwndParent - Handle to the window that owns anyUI elements (windows, dialog boxes, or message boxes) displayed by thisAPI. //  [IN] pszFileName - The path of the file to show licenseinformation for.

The FileDrmShowLicenseInfo function is free to return any HRESULT andthe application should use the SUCCEEDED/FAILED macros to check theresults. In addition, the following HRESULT codes may be returned.

//  [SUCCESS] //    S_FDRM_NOPROVIDER //    S_FDRM_NOTDRMOBJECT

A dialog is presented to the user showing the rights associated with thefile. This function returns when the user dismisses the dialog.

HRESULT FileDrmShowLicenseInfo (HWND hwndParent, LPCTSTR pszFileName);

The FileDrmHandleError function can facilitate displaying an errordialog to the user when an error occurs while trying to use DRM content.

// Arguments: //  [IN] hwndParent - Handle to the window that owns anyUI elements (windows, dialog boxes, or message boxes) displayed by thisAPI. //  [IN] hrError - The HRESULT error to display/handle //  [IN]pszFileName - The file associated with the error //  [IN] dwFlags -Flags controlling the API behavior. A bitmask comprised of FDRHF_*flags. //  [OUT] pdwStatus - Status returned by FileDRMHandleError. Abitmask comprised ofr FDRHF_* flags.

The function will only return the following HRESULTS. The applicationshould use SUCCEEDED/FAILED macros to check the return.

//  [SUCCESS] //    S_OK

The application may wish to check the FDRHF_RETRY andFDRHF_RIGHTSPENDING bits in *pdwFlags to control additional handling ofthe error.

//   [FAILURE] //     E_FDRM_ERRORNOTHANDLED

An application should handle the error. This will occur either becausethe FDRM provider cannot handle the error or does not recognize theerror. If the user requests a rights renewal, a network connection canbe established to send the renewal. Once the response is received anotification will be sent to registered applications.

When an error occurs while using one of the FDRM APIs thisFileDrmHandleError API can be called to display error information to theuser and (optionally) attempt to correct the error (most likely byoffering the user the option to acquire additional rights or extendexisting rights via UIs). If the user requests new/updated rights thenew/updated rights will arrive asynchronously. If the FDRHF_RETRY flagis set upon return from this function the application may retry theoperation that failed.

HRESULT FileDrmHandleError (HWND hwndParent, HRESULT hrError, LPCTSTRpszFileName, DWORD dwFlags, PDWORD pdwStatus);

Turning now to the FileDrmRenewRights API, its purpose is to renew therights associated with a DRM protected object.

// Arguments: //   [IN] hwndParent -Handle to the window that owns anyUI elements (e.g., windows, dialog boxes, or message boxes) displayed bythis API. //   [IN] pszFileName - Path to the file containing the DRMprotected object

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//   [SUCCESS] //     S_FDRM_NOPROVIDER //     S_FDRM_NOTDRMOBJECT //  [FAILURE] //     E_FDRM_NOTALLOWED //       Rights renewal is notallowed for this object type

A rights renewal request can be generated. This may cause a networkconnection to be opened.

This FileDrmRenewRights API allows an application to renew rightsassociated with a DRM protected object. In most cases the DRM providerwill handle this when FileDrmHandleError is called. New/updated rightscan arrive asynchronously.

HRESULT FileDrmRenewRights (HWND hwndParent, LPCTSTR pszFileName);

The FileDrmGetMetric function can retrieve metrics related to using DRMprotected objects.

// Arguments: //   [IN] drmID - Identifier to select which metric youwant. //   [OUT] pdwMetric -Pointer to a dword variable that will holdthe metric

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//   [FAILURE] //     E_FDRM_UNKNOWNMETRIC HRESULT FileDrmGetMetric(FDRMMETRIC drmID, DWORD *pdwMetric);

The FileDrmVerifyRights function can allow an application to verify thatan object has needed rights before using DRM protected objects.

// Arguments: //   [IN] hwndParent - Handle to the window that owns anyUI elements (e.g., windows, dialog boxes, or message boxes) displayed bythis API. //   [IN] pszFileName - Path to the file containing the DRMprotected object. //   [IN] dwRight - The right the application wants touse. Only one right may be specified. //   [IN] dwFlags - Flags tocontrol the behavior of FDRM_VerifyRights. This is a bitmask of FDRVF_*flag values.

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//   [SUCCESS] //     S_FDRM_NOPROVIDER //     S_FDRM_NOTDRMOBJECT //  [FAILURE] //     E_FDRM_FILEDELETED //     E_FDRM_CANCELLED //    E_FDRM_LICENSEPENDING //     E_FDRM_NOTALLOWED

In accordance with an aspect, before an application can use a DRMprotected object it should call the FileDrmVerifyRights API to ensurethat the object can be used as intended. As illustrated in themethodology of FIG. 12, it does this even if it has already calledFileDrmGetRights and done its own verification. This API will verify ifthe object has the appropriate rights, and if necessary, will prompt theuser to select at least between consuming rights or renewing expiredrights.

HRESULT FileDrmVerifyRights (HWND hwndParent, LPCTSTR pszFileName, DWORDdwRight, DWORD dwFlags, PDWORD pdwRightsStatus);

The FileDrmVerifyRightsEx API can facilitate an application to verifythat an object has needed rights before using DRM protected objects. Asdescribed supra, this API can also allow a user to filter content by itsintended use.

// Arguments: //   [IN] hwndParent - Handle to the window that owns anyUI elements (e.g., windows, dialog boxes, or message boxes) displayed bythis API. //   [IN] pszFileName - Path to the file containing the DRMprotected object //   [IN] dwRight - The right the application wants touse. Only one right may be specified. //   [IN] dwFlags - Flags tocontrol the behavior of FDRM_VerifyRights. This is a bitmap of FDRVF_*flag values. //     [OUT} pdwRightsStatus - Additional information aboutthe status of the right associated with the content. One of the FDRVS_*values. //       FDRVS_USER_CAN_UPDATE Right invalid but user can update//       FDRVS_UPDATE_PENDING A rights update is pending //    FDRVS_EXPIRABLE     Right is currently valid but can expire later.//     [IN] pGuidFilter -  An indication of the intended purpose of thecontent. If the content pointed to by pszFileName is DRM protected thisfilter value is checked as well as the rights associated with thecontent to determine if the content can be used.

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//   [SUCCESS] //     S_FDRM_NOPROVIDER //     S_FDRM_NOTDRMOBJECT //  [FAILURE] //     E_FDRM_FILEDELETED //     E_FDRM_CANCELLED //    E_FDRM_LICENSEPENDING //     E_FDRM_NOTALLOWED

In accordance with the exemplary aspect, either thisFileDrmVerifyRightsEx API or the FileDrmVerifyRights API is calledbefore an application can use a DRM protected object. TheFileDrmVerifyRightsEx API verifies if the object has the appropriaterights, and if necessary, will prompt the user to choose betweenconsuming rights or renewing expired rights.

HRESULT FileDrmVerifyRightsEx (HWND hwndParent, LPCTSTR pszFileName,DWORD dwRight, DWORD dwFlags, PDWORD pdwRightsStatus, LPGUIDpguidFilter);

Referring now to a description of the FileDrmCommitRights API, a purposeof this API is to facilitate an application that commits the rightsused.

// Arguments: //   [IN] hFile - Handle to the file containing the objectto be used. File should have been opened using FileDrmCreateFile ( ). //  [IN] dwRight - The right the application wants to use. Only one rightmay be specified. //   [IN] dwFlags - Flags to control the behavior ofFileDrmCommitRights. This is a bitmask of FDRVF_* flag values.

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//   [SUCCESS] //     S_FDRM_NOPROVIDER //     S_FDRM_NOTDRMOBJECT //  [FAILURE] //     E_FDRM_NOTALLOWED //     E_FDRM_LICENSEPENDING

This FileDrmCommitRights API commits the rights associated with anobject. The calling application calls FileDrmVerifyRights before thiscall.

HRESULT FileDrmCommitRights (HANDLE hFile, DWORD dwRight, DWORDdwFlags);

The FileDrmDeleteFile can facilitate deleting a DRM object as well asthe associated rights.

// Arguments: //   [IN] pszFileName - Path to the file containing theDRM protected object

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//   [SUCCESS] //     S_FDRM_NOPROVIDER //     S_FDRM_NOTDRMOBJECT

The rights store can be updated and the file containing the object canbe deleted. This API deletes both a DRM object and the associatedrights.

RESULT FileDrmDeleteFile (LPCTSTR pszFileName);

Turning now to a discussion of the FileDrmStoreContent API, this API canfacilitate reading a file containing MIME-encoded content to be DRMprotected and creating the device-locked version of that content, aswell as any associated rights or pending rights.

// Arguments: //   [IN] pszInputFileName - Fully qualified path to thefile containing MIME to be cracked. This file starts with theContent-Type (“Content-type: ...”) optionally preceeded by linear-white-space. //   [IN] pszOutputFileName - Fully qualified path to the file tohold the object contained within the MIME message. //   pvReserved -Unused. Should be set to NULL //   [OUT] pszMimeType - A pointer to thebuffer to be filled in with the type of the embedded object(“image/jpeg”). If this pointer is NULL then this call is to be treatedas a request to obtain the size of the buffer needed to hold the MIMEtype string. //   [IN/OUT] pcchMimeTypeLen - A pointer to a DWORDholding the length of the pszMimeType buffer in characters. On entrythis value will be the size of the passed buffer. On exit this will beset to the length of the MIME type string including the NUL terminator.

The function is free to return any HRESULT and the application shoulduse the SUCCEEDED/FAILED macros to check the results. In addition, thefollowing HRESULT codes may be returned.

//   [FAILURE] //     E_FDRM_NOPROVIDER //     E_INSUFFICIENT_BUFFER //    Output file not created and *pcchMimeTypeLen updated with neededbuffer size.

In accordance with this API, a new file can be created holding the DRMprotected content. As well, the original file can be deleted.

HRESULT FileDrmStoreContent (LPCTSTR pszInputFileName, LPCTSTRpszOutputFileName, PVOID pvReserved, LPTSTR pszMimeType, DWORD*pcchMimeTypeLen);

FIG. 13 illustrates a system 1300 that employs artificial intelligence(AI), which facilitates automating one or more features in accordancewith the subject invention. The subject invention (e.g., in connectionwith verifying rights) can employ various AI-based schemes for carryingout various aspects thereof. For example, a process for determining ifrights should be verified, renewed, etc., can be facilitated via anautomatic classifier system and process.

A classifier is a function that maps an input attribute vector, x=(x1,x2, x3, x4, xn), to a confidence that the input belongs to a class, thatis, f(x)=confidence(class). Such classification can employ aprobabilistic and/or statistical-based analysis (e.g., factoring intothe analysis utilities and costs) to prognose or infer an action that auser desires to be automatically performed. In the case of DRM, forexample, attributes can be words or phrases or other data-specificattributes derived from the words (e.g., the presence of key terms), andthe classes are categories or areas of interest (e.g., levels ofpriorities).

A support vector machine (SVM) is an example of a classifier that can beemployed. The SVM operates by finding a hypersurface in the space ofpossible inputs, which hypersurface attempts to split the triggeringcriteria from the non-triggering events. Intuitively, this makes theclassification correct for testing data that is near, but not identicalto training data. Other directed and undirected model classificationapproaches include, e.g., naive Bayes, Bayesian networks, decisiontrees, neural networks, fuzzy logic models, and probabilisticclassification models providing different patterns of independence canbe employed. Classification as used herein also is inclusive ofstatistical regression that is utilized to develop models of priority.

As will be readily appreciated from the subject specification, thesubject invention can employ classifiers that are explicitly trained(e.g., via a generic training data) as well as implicitly trained (e.g.,via observing user behavior, receiving extrinsic information). Forexample, SVM's are configured via a learning or training phase within aclassifier constructor and feature selection module. Thus, theclassifier(s) can be used to automatically learn and perform a number offunctions, including but not limited to determining according to apredetermined criteria when and if to obtain, renew or cancel rights.

Referring now to FIG. 14, there is illustrated a block diagram of acomputer operable to execute the disclosed architecture. In order toprovide additional context for various aspects of the subject invention,FIG. 14 and the following discussion are intended to provide a brief,general description of a suitable computing environment 1400 in whichthe various aspects of the invention can be implemented. While theinvention has been described above in the general context ofcomputer-executable instructions that may run on one or more computers,those skilled in the art will recognize that the invention also can beimplemented in combination with other program modules and/or as acombination of hardware and software.

Generally, program modules include routines, programs, components, datastructures, etc., that perform particular tasks or implement particularabstract data types. Moreover, those skilled in the art will appreciatethat the inventive methods can be practiced with other computer systemconfigurations, including single-processor or multiprocessor computersystems, minicomputers, mainframe computers, as well as personalcomputers, hand-held computing devices, microprocessor-based orprogrammable consumer electronics, and the like, each of which can beoperatively coupled to one or more associated devices.

The illustrated aspects of the invention may also be practiced indistributed computing environments where certain tasks are performed byremote processing devices that are linked through a communicationsnetwork. In a distributed computing environment, program modules can belocated in both local and remote memory storage devices.

A computer typically includes a variety of computer-readable media.Computer-readable media can be any available media that can be accessedby the computer and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer-readable media can comprise computer storage mediaand communication media. Computer storage media includes volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information such as computer-readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital video disk (DVD) orother optical disk storage, magnetic cassettes, magnetic tape, magneticdisk storage or other magnetic storage devices, or any other mediumwhich can be used to store the desired information and which can beaccessed by the computer.

Communication media typically embodies computer-readable instructions,data structures, program modules or other data in a modulated datasignal such as a carrier wave or other transport mechanism, and includesany information delivery media. The term “modulated data signal” means asignal that has one or more of its characteristics set or changed insuch a manner as to encode information in the signal. By way of example,and not limitation, communication media includes wired media such as awired network or direct-wired connection, and wireless media such asacoustic, RF, infrared and other wireless media. Combinations of the anyof the above should also be included within the scope ofcomputer-readable media.

With reference again to FIG. 14, the exemplary environment 1400 forimplementing various aspects of the invention includes a computer 1402,the computer 1402 including a processing unit 1404, a system memory 1406and a system bus 1408. The system bus 1408 couples system componentsincluding, but not limited to, the system memory 1406 to the processingunit 1404. The processing unit 1404 can be any of various commerciallyavailable processors. Dual microprocessors and other multi-processorarchitectures may also be employed as the processing unit 1404.

The system bus 1408 can be any of several types of bus structure thatmay further interconnect to a memory bus (with or without a memorycontroller), a peripheral bus, and a local bus using any of a variety ofcommercially available bus architectures. The system memory 1406includes read-only memory (ROM) 1410 and random access memory (RAM)1412. A basic input/output system (BIOS) is stored in a non-volatilememory 1410 such as ROM, EPROM, EEPROM, which BIOS contains the basicroutines that help to transfer information between elements within thecomputer 1402, such as during start-up. The RAM 1412 can also include ahigh-speed RAM such as static RAM for caching data.

The computer 1402 further includes an internal hard disk drive (HDD)1414 (e.g., EIDE, SATA), which internal hard disk drive 1414 may also beconfigured for external use in a suitable chassis (not shown), amagnetic floppy disk drive (FDD) 1416, (e.g., to read from or write to aremovable diskette 1418) and an optical disk drive 1420, (e.g., readinga CD-ROM disk 1422 or, to read from or write to other high capacityoptical media such as the DVD). The hard disk drive 1414, magnetic diskdrive 1416 and optical disk drive 1420 can be connected to the systembus 1408 by a hard disk drive interface 1424, a magnetic disk driveinterface 1426 and an optical drive interface 1428, respectively. Theinterface 1424 for external drive implementations includes at least oneor both of Universal Serial Bus (USB) and IEEE 1394 interfacetechnologies. Other external drive connection technologies are withincontemplation of the subject invention.

The drives and their associated computer-readable media providenonvolatile storage of data, data structures, computer-executableinstructions, and so forth. For the computer 1402, the drives and mediaaccommodate the storage of any data in a suitable digital format.Although the description of computer-readable media above refers to aHDD, a removable magnetic diskette, and a removable optical media suchas a CD or DVD, it should be appreciated by those skilled in the artthat other types of media which are readable by a computer, such as zipdrives, magnetic cassettes, flash memory cards, cartridges, and thelike, may also be used in the exemplary operating environment, andfurther, that any such media may contain computer-executableinstructions for performing the methods of the invention.

A number of program modules can be stored in the drives and RAM 1412,including an operating system 1430, one or more application programs1432, other program modules 1434 and program data 1436. All or portionsof the operating system, applications, modules, and/or data can also becached in the RAM 1412. It is appreciated that the invention can beimplemented with various commercially available operating systems orcombinations of operating systems.

A user can enter commands and information into the computer 1402 throughone or more wired/wireless input devices, e.g., a keyboard 1438 and apointing device, such as a mouse 1440. Other input devices (not shown)may include a microphone, an IR remote control, a joystick, a game pad,a stylus pen, touch screen, or the like. These and other input devicesare often connected to the processing unit 1404 through an input deviceinterface 1442 that is coupled to the system bus 1408, but can beconnected by other interfaces, such as a parallel port, an IEEE 1394serial port, a game port, a USB port, an IR interface, etc.

A monitor 1444 or other type of display device is also connected to thesystem bus 1408 via an interface, such as a video adapter 1446. Inaddition to the monitor 1444, a computer typically includes otherperipheral output devices (not shown), such as speakers, printers, etc.

The computer 1402 may operate in a networked environment using logicalconnections via wired and/or wireless communications to one or moreremote computers, such as a remote computer(s) 1448. The remotecomputer(s) 1448 can be a workstation, a server computer, a router, apersonal computer, portable computer, microprocessor-based entertainmentappliance, a peer device or other common network node, and typicallyincludes many or all of the elements described relative to the computer1402, although, for purposes of brevity, only a memory/storage device1450 is illustrated. The logical connections depicted includewired/wireless connectivity to a local area network (LAN) 1452 and/orlarger networks, e.g., a wide area network (WAN) 1454. Such LAN and WANnetworking environments are commonplace in offices and companies, andfacilitate enterprise-wide computer networks, such as intranets, all ofwhich may connect to a global communications network, e.g., theInternet.

When used in a LAN networking environment, the computer 1402 isconnected to the local network 1452 through a wired and/or wirelesscommunication network interface or adapter 1456. The adaptor 1456 mayfacilitate wired or wireless communication to the LAN 1452, which mayalso include a wireless access point disposed thereon for communicatingwith the wireless adaptor 1456.

When used in a WAN networking environment, the computer 1402 can includea modem 1458, or is connected to a communications server on the WAN1454, or has other means for establishing communications over the WAN1454, such as by way of the Internet. The modem 1458, which can beinternal or external and a wired or wireless device, is connected to thesystem bus 1408 via the serial port interface 1442. In a networkedenvironment, program modules depicted relative to the computer 1402, orportions thereof, can be stored in the remote memory/storage device1450. It will be appreciated that the network connections shown areexemplary and other means of establishing a communications link betweenthe computers can be used.

The computer 1402 is operable to communicate with any wireless devicesor entities operatively disposed in wireless communication, e.g., aprinter, scanner, desktop and/or portable computer, portable dataassistant, communications satellite, any piece of equipment or locationassociated with a wirelessly detectable tag (e.g., a kiosk, news stand,restroom), and telephone. This includes at least Wi-Fi and Bluetooth™wireless technologies. Thus, the communication can be a predefinedstructure as with a conventional network or simply an ad hoccommunication between at least two devices.

Wi-Fi, or Wireless Fidelity, allows connection to the Internet from acouch at home, a bed in a hotel room, or a conference room at work,without wires. Wi-Fi is a wireless technology similar to that used in acell phone that enables such devices, e.g., computers, to send andreceive data indoors and out; anywhere within the range of a basestation. Wi-Fi networks use radio technologies called IEEE 802.11 (a, b,g, etc.) to provide secure, reliable, fast wireless connectivity. AWi-Fi network can be used to connect computers to each other, to theInternet, and to wired networks (which use IEEE 802.3 or Ethernet).Wi-Fi networks operate in the unlicensed 2.4 and 5 GHz radio bands, atan 11 Mbps (802.11a) or 54 Mbps (802.11b) data rate, for example, orwith products that contain both bands (dual band), so the networks canprovide real-world performance similar to the basic 10BaseT wiredEthernet networks used in many offices.

Referring now to FIG. 15, there is illustrated a schematic block diagramof an exemplary computing environment 1500 in accordance with thesubject invention. The system 1500 includes one or more client(s) 1502.The client(s) 1502 can be hardware and/or software (e.g., threads,processes, computing devices). The client(s) 1502 can house cookie(s)and/or associated contextual information by employing the invention, forexample.

The system 1500 also includes one or more server(s) 1504. The server(s)1504 can also be hardware and/or software (e.g., threads, processes,computing devices). The servers 1504 can house threads to performtransformations by employing the invention, for example. One possiblecommunication between a client 1502 and a server 1504 can be in the formof a data packet adapted to be transmitted between two or more computerprocesses. The data packet may include a cookie and/or associatedcontextual information, for example. The system 1500 includes acommunication framework 1506 (e.g., a global communication network suchas the Internet) that can be employed to facilitate communicationsbetween the client(s) 1502 and the server(s) 1504.

Communications can be facilitated via a wired (including optical fiber)and/or wireless technology. The client(s) 1502 are operatively connectedto one or more client data store(s) 1508 that can be employed to storeinformation local to the client(s) 1502 (e.g., cookie(s) and/orassociated contextual information). Similarly, the server(s) 1504 areoperatively connected to one or more server data store(s) 1510 that canbe employed to store information local to the servers 1504.

What has been described above includes examples of the invention. It is,of course, not possible to describe every conceivable combination ofcomponents or methodologies for purposes of describing the subjectinvention, but one of ordinary skill in the art may recognize that manyfurther combinations and permutations of the invention are possible.Accordingly, the invention is intended to embrace all such alterations,modifications and variations that fall within the spirit and scope ofthe appended claims. Furthermore, to the extent that the term “includes”is used in either the detailed description or the claims, such term isintended to be inclusive in a manner similar to the term “comprising” as“comprising” is interpreted when employed as a transitional word in aclaim.

1. A method of providing DRM-protected content, comprising: adding a plug-in DRM API to an application; the plug-in DRM API enables the application to support a plurality of disparate DRM engines; selecting an object; verifying a DRM right associated with the object; and committing the DRM right used by the object.
 2. The method of claim 1, further comprising at least one of the acts of enabling a DRM provider notification and disabling the DRM provider notification.
 3. The method of claim 1, further comprising launching a UI that updates the DRM right.
 4. The method of claim 1, further comprising renewing the DRM right used by the object.
 5. The method of claim 1, further comprising an act of converting the application into a DRM aware application using the DRM API.
 6. A system that facilitates employing DRM-protected content, comprising: means for receiving a create request from an application that facilitates opening a file; means for calling a content handler that facilitates storing content of the file in a device file system and storing a content DRM right in a rights store; means for verifying the content DRM right; means for employing the content if the content DRM right is valid; means for obtaining an updated DRM right if the content DRM right is not valid; and means for committing at least one of the content DRM right and the updated DRM right.
 7. A pluggable API layer that employs the system of claim 6 to convert the application into a DRM aware application.
 8. A system for providing DRM-protected content, comprising: a computing processor; computing memory communicatively coupled with the computing processor, the computing memory having stored thereon instructions that cause the computing processor to perform operations comprising: adding a plug-in DRM API to an application, the plug-in DRM API enabling the application to support a plurality of disparate DRM engines; selecting an object; verifying a DRM right associated with the object; and committing the DRM right used by the object.
 9. The system of claim 8, the computing memory having stored thereon instructions that cause the computing processor to perform at least one of: enabling a DRM provider notification; and disabling the DRM provider notification.
 10. The system of claim 8, the computing memory having stored thereon instructions that cause the computing processor to perform launching a UI that updates the DRM right.
 11. The system of claim 8, the computing memory having stored thereon instructions that cause the computing processor to perform renewing the DRM right used by the object.
 12. The system of claim 8, the computing memory having stored thereon instructions that cause the computing processor to perform converting the application into a DRM aware application using the DRM API. 